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Oracle Server / PL/SQL 


Fast and Dangerous 


The Misunderstood Oracle ROWID 


By Bert Scalzo, Ph.D. 


he Oracle ROWID is an important and powerful SQL programming tool. 
However, ROWIDs have a history of being somewhat misunderstood, espe- 
cially regarding when and how they can safely be used. 


Under the right circumstances, ROWIDs 
can make your SQL and/or PL/SQL 


code run faster. 


But beware! ROWIDs also have the ability 
to make your program behave erratically 
— or not at all. Therefore, the ROWID 


must be treated with great respect. 


Just What Is It Exactly? 

What is an Oracle ROWID? Every row 
in an Oracle table is assigned a physical 
address known as its ROWID. For non- 
clustered tables, these addresses are 
unique. For clustered tables, rows that 
are from different tables, but are located 
within the same data block, will have 


identical ROWIDs. 


While one may project and restrict using 
the ROWID much like any other col- 
umn in a table, it is nonetheless a pseu- 
do-column. Oracle pseudo-columns are 
not actually part of the table, and as 
such do not show up in a table describe. 
Nonetheless, they are quite useful. 


Other examples of pseudo-columns 
include CURRVAL and NEXTVAL 
(sequence number generators), LEVEL 
(for hierarchical queries), and 


ROWNUM (a row’s relative number). 


Internally, ROWID is a binary value. 


Externally, however, it is displayed as a 


three-part hexadecimal string stored in a 


VARCHAR2 column. 


The first part (positions 1 through 8) is 
the block ID; the second part (positions 
10 through 13) is the sequence number of 
the row within the block; and the third 
part (positions 15 through 18) is the data 
file ID. 


You can separate ROWID into its compo- 
nents using the SUBSTR function. 


This SELECT statement for example: 


SELECT ROWID, 


SUBSTR(ROWID, 15, 4) AS "FILE", 
SUBSTR(ROWID, 1, 8) AS "BLOCK", 
SUBSTR(ROWID, 10, 4) AS "ROW" 
FROM dual; 
might yield: 
ROWIDFILEBLOCKROW 


0000033D .0000 .000100010000033D0000 


Or, easier to read: 


ROWID 0000033D.0000.0001 
File 0001 


Block 0000033D 


In this example, the row is the first row 





within its block (because its row offset 
within the block is zero). Moreover, it is 
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located in the 829 block within data file one. This is 
the row’s physical address. 


It’s Fast! 

Accessing a table’s rows using the ROWID is fast. In fact, the 
rule-based optimizer considers access by ROWID as the 
highest ranked access method. 


The rules for access path selection, according to the Oracle 


Application Developers Guide, are listed in Figure 1. 


Access Path 


Single row by hash cluster key with unique or primary key 


Single row by unique or primary key 
Cluster join 


Hash cluster key 


Indexed cluster key 
Composite key 
Single-column indexes 


9 
Bounded range search on indexed columns 


Figure 1: The rules for access path selection. 


As you can see, the first — and therefore fastest — 
access method is the ROWID. This access path will only 
be available if: 


m the statements WHERE clause identifies the selected 
rows by ROWID, 
® or with the CURRENT OF CURSOR clause. 


If one of these criterion is met, the Oracle server can 
access the data rows via their physical address. The result 
is lightning-fast access. 


This ultra-fast access technique has an Achilles heal, howev- 


er: ROWIDs can change. 


Ch... Ch... Changes 


The address of a row can change under different circum- 
stances. For example, an export followed by an import 
will usually result in different ROWIDs. However, this 
is an innocuous example. Because the ROWID is chang- 
ing outside the realm of the user’s transactions, there is 
no reason for concern. 


Contrast this to a ROWID changing during the pro- 
cessing of one’s DML operations. If you have relied on 
a ROWID being consistent for the entire scope of your 
program, you may be in real trouble: 





PROCEDURE transfer_all 
(commit_after_in IN INTEGER -= 100, 


requery_after_in IN INTEGER := 1000) 
IS 
more _data BOOLEAN = TRUE; 
commit_count INTEGER := 0; 


CURSOR trans _cur 
IS 
SELECT ROWID FROM transfer_table 
WHERE transfer_indictor = '‘U' 
AND ROWNUM <= requery_after_in; 
BEGIN 
WHILE more_data 
LOOP 
more data := FALSE; 
FOR trans_rec IN trans_cur 
LOOP 
more data := TRUE; 


INSERT INTO master_table 
SELECT 

FROM transfer_table 
WHERE ROWID = trans_rec.ROWID; 


UPDATE transfer_table 
SET transfer_indicator = 'T' 
WHERE ROWID = trans_rec.ROWID; 


commit count := commit _count + 1; 
IF commit_count = commit_after_in 
THEN 

COMMIT ; 

commit count := 0; 
END IF; 


END LOOP; 
END LOOP; 
END; 


Figure 2: The transfer_all procedure. 


ROWIDs are only guaranteed to be consistent during the 
length of a transaction. 


An Oracle transaction starts the moment you connect 
until either a COMMIT or ROLLBACK occurs, at 
which time another transaction begins. Hence, 
ROWIDs may change within the scope of your pro- 


gram if you have more than one transaction. 


An Example 

A perfect example of this problem is the transfer_all 
procedure (see Figure 2) that is the solution to April’s 
PL/SQL challenge (see page 63 of the May 1996 issue 
of Oracle Informant). This PL/SQL procedure con- 
structs a cursor, TRANS CUR, from selected ROWIDs 


that match some restriction criteria. 


Then, the code has a cursor FOR loop that steps 
through those returned rows. The loop includes both 
INSERT and UPDATE DML commands that reference 
the ROWID of the current cursor record. 


Also inside this cursor FOR loop is a COMMIT state- 
ment that is executed at every threshold interval as 
indicated by the commit-count variable. When a 
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COMMIT occurs, the ROWIDs held by the cursor are 


free to change. 


Still, no problem is likely to occur in a single-user envi- 
ronment. But in a multi-user, concurrent transaction envi- 
ronment, this code could very easily have problems: 


m Another user could perform UPDATEs, INSERTs, or 
DELETEs that would invalidate your ROWIDs. 

m In addition, free space compression which occurs inter- 
nally and automatically during INSERTs, and 
UPDATES that decrease lengths, can also alter 
ROWIDs. 


This problem might never manifest itself. More likely, 
however, it would be one of those weird, nagging errors 
that is hard to reproduce, and nearly impossible to debug. 


Conclusion 
ROWIDs should be used sparingly, and under stringent 
guidelines. My rule is that one should never use a ROWID 


across SQL statements without locking those rows. 


The Oracle7 Server Concept Manual asserts “Before 
ROW IDs are used in DML statements, they should be 
verified and guaranteed not to change; the intended 
rows should be locked so they cannot change.” 


And Oracle Performance Tuning [Corrigan and Gurry, 
O’Reilly & Associates, 1993] states “Remember when 
you first query the record, to select the record for 


update. This keeps another process from being able to 
update the selected record and change its ROWID out 


from under you.” 


In the case of the transfer_all procedure, two changes 


would be necessary to fix the PL/SQL code. First, add: 


FOR UPDATE OF ROWID 


to the cursor declaration. Second, move the COMMIT 
statement outside the FOR loop. While this may seem to 
make the program less flexible, it nonetheless makes it 


entirely reliable. El 
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